Auto merge of #2915 - matklad:rename-shell, r=alexcrichton

Minor, rename function parameter

Naming `Config` as `shell` (while having a `shell` function in scope which returns `MultiShell`) inside this not so trivial callback driven fragment of code is devilishly evil :)

Auto merge of #2910 - BusyJay:master, r=alexcrichton

Fix python detection

Some platform, like ArchLinux, may not have python in the PATH, but can still have python2. So we should add some fallback option to detect python correctly. This detection order is copy from [rust-lang/rust](https://github.com/rust-lang/rust/blob/master/configure#L742).

Auto merge of #2913 - cuviper:disable-option-checking, r=alexcrichton

configure: Support --disable-option-checking

This is mirroring rust-lang/rust#31169.  The RPM %configure macro sets a
lot of useful paths for typical configure scripts, but some of these
values are not recognized here in Cargo.  It's nice to have an option to
ignore those, rather than failing on `validate_opt`.

Minor, rename function parameter

Auto merge of #2912 - matklad:move-target-dir, r=alexcrichton

Move `target_dir` to Workspace and fix #2848

Target dir is now an API of Workspace. It is still initialized eagerly, just later.

I also had to errors in the config file when retrieving `verbose` and `color` config. Seems fishy, but is probably OK.

configure: Support --disable-option-checking

This is mirroring rust-lang/rust#31169.  The RPM %configure macro sets a
lot of useful paths for typical configure scripts, but some of these
values are not recognized here in Cargo.  It's nice to have an option to
ignore those, rather than failing on `validate_opt`.

Fix config loading test

Ignore some config errors during init

While it is generally terrible to silently ignore errors in the
configuration files, it is acceptable in this case. Verbosity and color
config have reasonable defaults, and we don't want to fail for simple
commands like `cargo --version` just because of the garbage in the
config file.

fixed #2848

Read target config later

Fix python detection

Move `target_dir` to workspace

Auto merge of #2908 - froydnj:spelling-fixes, r=alexcrichton

fix typos in src/doc/manifest.md

A few things I noticed while reading the documentation.  The "sections" change is not strictly a spelling error, but I figured I would fix it while I was in the area.

fix typos in src/doc/manifest.md

Auto merge of #2907 - alexcrichton:alias-no-override, r=brson

Don't allow aliases to override builtin commands

Closes #2901

Don't allow aliases to override builtin commands

Closes #2901

Auto merge of #2900 - matklad:lazy-config, r=alexcrichton

Lazy config

Next piece of #2848.

* `config.rustc`  and `config.rustdoc` are now lazy.
* `Rustc` and not `config.rustc` now knows the path to the compiler.
* `LazyCell` is used to implement laziness

No new tests are added, because we need to lazify `target_path` to deal with broken cargo config.

`target_path` is a bit peculiar. It is always accessed as `ws.config.target_path(ws)`, and has a setter. Perhaps it belongs to the workspace? Will look into that later.

Use LazyCell to implement lazy Config

Coalesce config.rustc and config.rustc_info

Move path to rustc into Rustc struct

Scrape tools config lazily

Auto merge of #2811 - alexcrichton:network-is-error, r=brson

Add a flag to force network access to be an error

If a lock file is generated and some equivalent of `cargo fetch` is run then
Cargo shouldn't ever touch the network or modify `Cargo.lock` until any
`Cargo.toml` later changes, but this often wants to be asserted in some build
environments where it's a programmer error if Cargo attempts to access the
network.

The `--locked` flag added here will assert that `Cargo.lock` does not need to
change to proceed. That is, if `Cargo.lock` would be modified (as it
automatically is by default) this is turned into a hard error instead.

This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same
behavior as `--locked`), but it will also will manually prevent Cargo from
touching the network by ensuring that all network requests return an error.

These flags can be used in environments where it is *expected* that no network
access happens (or no lockfile changes happen) because it has been pre-arranged
for Cargo to not happen. Examples of this include:

* CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to
  date before changes are checked in.
* Environments with vendored dependencies want to pass `--frozen` as touching
  the network indicates a programmer error that something wasn't vendored
  correctly.

A crucial property of these two flags is that **they do not change the behavior
of Cargo**. They are simply assertions at a few locations in Cargo to ensure
that actions expected to not happen indeed don't happen. Some documentation has
also been added to this effect.

Closes #2111

Auto merge of #2893 - KasMA1990:patch-1, r=alexcrichton

Include reference to Rust code structuring

Hey guys, I'm proposing this little addition to the manifest. When I first started with Rust, I wanted to make a simple crate, so the "Getting Started" (and from there, the manifest) document on crates.io was a natural entry point for me. However, it would have helped getting over some headaches initially if the Cargo documentation had driven me into the relevant Rust documentation; in the beginning at least it wasn't clear to me where Cargo ended and Rust began, especially with modules.

I'm not sure if this should be in the actual manifest or in the "Getting Stated" doc, or if you want it there at all, but it's a quality-of-life thing that I think past-me would have appreciated at least :)

Include reference to Rust code structuring

Add flags to assert lock/cache behavior to Cargo

If a lock file is generated and some equivalent of `cargo fetch` is run then
Cargo shouldn't ever touch the network or modify `Cargo.lock` until any
`Cargo.toml` later changes, but this often wants to be asserted in some build
environments where it's a programmer error if Cargo attempts to access the
network.

The `--locked` flag added here will assert that `Cargo.lock` does not need to
change to proceed. That is, if `Cargo.lock` would be modified (as it
automatically is by default) this is turned into a hard error instead.

This `--frozen` will not only assert that `Cargo.lock` doesn't change (the same
behavior as `--locked`), but it will also will manually prevent Cargo from
touching the network by ensuring that all network requests return an error.

These flags can be used in environments where it is *expected* that no network
access happens (or no lockfile changes happen) because it has been pre-arranged
for Cargo to not happen. Examples of this include:

* CI for projects want to pass `--locked` to ensure that `Cargo.lock` is up to
  date before changes are checked in.
* Environments with vendored dependencies want to pass `--frozen` as touching
  the network indicates a programmer error that something wasn't vendored
  correctly.

A crucial property of these two flags is that **they do not change the behavior
of Cargo**. They are simply assertions at a few locations in Cargo to ensure
that actions expected to not happen indeed don't happen. Some documentation has
also been added to this effect.

Closes #2111

Auto merge of #2891 - upsuper:fix-search-path, r=alexcrichton

Search dylib path from cargo before system

Cargo should have more knowledge about what it is looking for, and thus its paths should be more correct compared to system's. When there are conflicts, the search paths provided by the build system should take priority.

Search dylib path from cargo before system

Cargo should have more knowledge about what it is looking for, and thus
its paths should be more correct compared to system's. When there are
conflicts, the search paths provided by the build system should take
priority.

Auto merge of #2849 - wezm:publish_dry_run, r=alexcrichton

Add --dry-run to cargo publish

This PR picks up where @JustAPerson left off in https://github.com/rust-lang/cargo/pull/1699. I've updated their changes to apply to current master and added tests, including (I think) a test that checks that the upload doesn't actually occur.

The output is as it was before:


Closes https://github.com/rust-lang/cargo/issues/1332

Auto merge of #2889 - bennofs:fix-cargo-rustc-help, r=alexcrichton

fix help for cargo rustc -p

cargo rustc -p does the same as cargo build -p, so I just copied it from there.

Add --dry-run option to publish sub-command

Squashed commit of the following:

commit deed1d7b99c1cd142f7782d3b3b782d949e1f71f
Author: Wesley Moore <wes@wezm.net>
Date:   Fri Jul 15 13:35:01 2016 +1000

    Remove --dry-run and --no-verify mutual exclusion

commit 8a91fcf2a1aa3ba682fee67bb5b3e7c2c2cce8ef
Merge: 0c0d057 970535d
Author: Wesley Moore <wes@wezm.net>
Date:   Fri Jul 15 13:30:38 2016 +1000

    Merge remote-tracking branch 'upstream/master' into publish_dry_run

commit 0c0d0572533599b3c0e42797a6014edf480f1dc2
Author: Wesley Moore <wes@wezm.net>
Date:   Tue Jul 12 08:03:15 2016 +1000

    Improve grammar in --dry-run option

commit a17c1bf6f41f016cafdcb8cfc58ccbe34d54fbb8
Author: Wesley Moore <wes@wezm.net>
Date:   Mon Jul 11 14:17:41 2016 +1000

    Add test for passing no-verify and dry-run to publish

commit 284810cca5df3268596f18700c0247de2f621c98
Author: Wesley Moore <wes@wezm.net>
Date:   Mon Jul 11 14:51:38 2016 +1000

    Add test for publish --dry-run

commit 8514e47fbce61c20b227815887a377c25d17d004
Merge: 2b061c5 ef07b81
Author: Wesley Moore <wes@wezm.net>
Date:   Mon Jul 11 08:27:10 2016 +1000

    Merge branch 'publish_dry_run' of github.com:JustAPerson/cargo into publish_dry_run

commit ef07b81617df855328c34365b28049cd9742946c
Author: Jason Priest <jpriest128@gmail.com>
Date:   Tue Jun 9 23:11:51 2015 -0500

    Improve publish `--dry-run`

    Catch a few more errors by aborting midway through transmit().

commit 0686fb0bf92a09bcbd41e15e23ff03a0763c5d08
Author: Jason Priest <jpriest128@gmail.com>
Date:   Tue Jun 9 14:38:58 2015 -0500

    Teach publish the `--dry-run` flag

    Closes #1332

fix help for cargo rustc -p

Auto merge of #2887 - wuranbo:doc-explain-doublebrackets, r=alexcrichton

doc: manifest.md add explain about double-bracket

Add TOML doc ref to explain double-bracket sections like [[bin]].
It really confused me when I saw the double-bracket first. I search google, take some time, and then saw the TOML doc, recall that we can have more than one executable in Cargo, understood it. So it can be added to help someone like me (:

doc: manifest.md add explain about double-bracket

Auto merge of #2885 - nelhage:ssh-retry-loop, r=alexcrichton

git: only attempt ssh-agent authentication once

This prevents infinite looping if ssh-agent authentication fails.

closes #2845

git: only attempt ssh-agent authentication once

This prevents infinite looping if ssh-agent authentication fails.

closes #2845

Auto merge of #2883 - wuranbo:patch-1, r=alexcrichton

doc: typo

doc: typo

Auto merge of #2881 - matklad:lazy-rustc-info, r=alexcrichton

Lazy rustc info

This is the first step towards https://github.com/rust-lang/cargo/issues/2848.

Remove now unnecessary Rustc::blank method

Retrieve Rustc info lazily

Auto merge of #2879 - QuiltOS:replace-bug, r=alexcrichton

Fix #2595 by skipping reflexive replacements

If you know of something better than `source_id == source_id`, I'd gladly change it.

Merge branch 'master' into replace-bug

Fix #2595 by skipping reflexive replacements

Refactor replacement logic

Add minimal version of #2595 to test suite (test currently fails)

Auto merge of #2876 - bennofs:fix-2851, r=alexcrichton

allow enabling features for deps with --features

Fixes #2851

allow enabling features for deps with --features

Fixes #2851

Auto merge of #2873 - integer32llc:typo, r=alexcrichton

Fix typo in logging statement

Fix typo in logging statement

Auto merge of #2858 - QuiltOS:parser-clean, r=alexcrichton

Parser clean

A few misc shortenings, mainly from my stdlib deps prototype. See the TODOs for some questions.

Auto merge of #2870 - matklad:add-host-triple, r=alexcrichton

Refactor `host/target_triple` handling

This PR adds an explicit `host_triple` filed to `BuildConfig`. It allows to unify host and target handling and to reduce the number of accesses to `config.rustc_info()`. As a side effect, the explicit `target_triple` field of `Context` is gone because it can now be calculated from the `BuildConfig`.

Auto merge of #2679 - sbeckeriv:alias, r=alexcrichton

Command alias or Alias command #1091

Dearest Reviewer,

This pull request closes #1091 which is a request to support aliases.
This is not as powerful as something like git's alias, however, I think
it sticks true to the original request.

I high jack the processing of the args. After a few flags are checked
and the args are parsed I check the config file for alias.COMMAND. If it
is there I split it like args does and replace args[1] (the original
command) with the alias command and its 'flags'.

As an extra measure I output the alias command with warn. I would be
willing to drop that or put it behind a verbose flag. Also the docs have
been updated.

Thanks!
Becker

<img width="784" alt="screen shot 2016-05-12 at 10 23 59 am" src="https://cloud.githubusercontent.com/assets/12170/15226012/d18a3336-1835-11e6-94c9-875a63a79856.png">

Add explicit host_triple to BuildConfig

Auto merge of #2867 - mattscamp:add_jobs_flag, r=alexcrichton

Add jobs flag to package

https://github.com/rust-lang/cargo/issues/2860

Move private function near the one area it is used

Cleanup conversion of TOML to `SourceId`

Use flat_map to more concisely iterator through Options

Introduce `Context::host_triple` method

Add jobs flag to package

Auto merge of #2863 - QuiltOS:specified-req, r=alexcrichton

Make the `DependencyInner::specified_req` field a bool.

I could almost get rid if it completely, but then the dependency verifier would have to abort on, say, no version req specified or the any req. Crates.io indeed doesn't want wildcards, but other registries some day may have a different policy.

Making it a mere bool---since all the information it contained is on the `req` field anyways---was the next best thing.

Make the `DependencyInner::specified_req` field a bool.

This field is hardly used. I could almost get rid if it completely, but
then the dependency verifier would have to abort on, say, no version req
specified or the any req. Crates.io indeed doesn't want such wildcards, but
other registries some day may have a different policy.

Making it a mere bool---since all the information it contained is in the
`req` field anyways---was the next best thing.

Auto merge of #2862 - alexcrichton:update-rust, r=alexcrichton

Update the rust nightly to build cargo nightlies

Right now Cargo doesn't work on OSX 10.12, but the fix is in upstream rustc, so
let's pick that up and make Cargo nightlies compatible as well.

Update the rust nightly to build cargo nightlies

Right now Cargo doesn't work on OSX 10.12, but the fix is in upstream rustc, so
let's pick that up and make Cargo nightlies compatible as well.

Tiny cleanup: functional update > mutation

Auto merge of #2853 - matklad:reduce-duplication, r=alexcrichton

Reduce duplication in `Context` creation

There was some duplicated code for `Context` creation in `cargo_clean` and `cargo_rustc`. I've tried to remove it by moving the common part into `Context::new`. Not sure that this is the right thing to do though, it's just something I came across while tracing `rustc_info` flow.

Additional possible refactoring would be to remove `Default` bound from `BuildConfig`.

Auto merge of #2852 - alexcrichton:doc-env-vars, r=alexcrichton

Document the RUSTC/RUSTDOC build script env vars

Document the RUSTC/RUSTDOC build script env vars

Reduce duplication in `Context` creation

Auto merge of #2830 - munyari:rustc-env, r=alexcrichton

Set environment variable for rustc in custom_build.rs

Addresses #2819

Assert that RUSTC and RUSTDOC are set correctly

Auto merge of #2842 - alx741:update_manpages, r=alexcrichton

Update manpages with new flags

Add the [new flags](http://blog.rust-lang.org/2016/07/07/Rust-1.10.html)

Man pages: add 'force' flag

Man pages: add 'doc' flag

Man pages: add 'explain' flag

Auto merge of #2839 - alexcrichton:same-root, r=brson

Generate the same lock always in a workspace

Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.

Closes #2837

Generate the same lock always in a workspace

Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.

Closes #2837

Auto merge of #2840 - matklad:remove-dead-code, r=alexcrichton

Remove dead code

Are these functions necessary for some reason?

Remove dead code

Auto merge of #2835 - alexcrichton:bump, r=alexcrichton

Bump to 0.13.0

Bump to 0.13.0

Command alias or Alias command #1091

Dearest Reviewer,

This pull request closes #1091 which is a request to support aliases.
This is not as powerful as something like git's alias, however, I think
it sticks true to the original request.

I high jack the processing of the args. After a few flags are checked
and the args are parsed I check the config file for alias.COMMAND. If it
is there I split it like args does and replace args[1] (the original
command) with the alias command and its 'flags'.

I have also included default short hand commands b, t and r.

Thanks!
Becker

Auto merge of #2815 - alexcrichton:lets-add-some-docs, r=brson

Document the [replace] section

Thought I did this before, but apparently forgot!

Document the [replace] section

Thought I did this before, but apparently forgot!

Set environment variable for rustdoc in custom_build.rs

Auto merge of #2828 - bennofs:cargo-repackage, r=alexcrichton

cargo package: overwrite existing tarballs

Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.

This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.

Fixes #2799

Set environment variable for rustc in custom_build.rs

Auto merge of #2829 - brson:doc, r=alexcrichton

Use consistent capitalization in doc headers

There was a pretty even mix of upper-case and lower-case, so I chose lower. This appears to be consistent with other rust docs.

cargo package: overwrite existing tarballs

Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.

This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.

Fixes #2799

Auto merge of #2794 - alexcrichton:rustdocflags, r=brson

Add support for RUSTDOCFLAGS

Like with RUSTFLAGS, parse this variable to pass along extra arguments to
invocations of `rustdoc`.

Use consistent capitalization in doc headers

Auto merge of #2759 - alexcrichton:workspaces, r=brson

Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].

Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].

Auto merge of #2826 - KaivoAnastetiks:fix/no-subcommand-name, r=alexcrichton

Display the name of the unknown subcommand.

?r @alexcrichton
Fixes #2825

Splits a test on two lines to keep it below 100 chars.

Add a test for invalid subcommand displayed on error.

Display the name of the unknown subcommand.

Auto merge of #2822 - munyari:owner-man, r=alexcrichton

Add owner subcommand to cargo's man page

Addresses #2789

Add man page for owner subcommand

Auto merge of #2821 - bennofs:no-transitive-dep-feature, r=alexcrichton

Disallow specifying features of transitive deps

Before this commit, it was possible to activate a feature in a transtive
dependency, using a Cargo.toml like the following one:

    ...
    [features]
    # this will enable feature fast in package bar, which is a
    # dependency of foo
    default = [ foo/bar/fast ]

This is a bug, and was never intended, and it is checked in other places
already. The behavior was possible because `build_features::add_feature`
treats the specification "foo/bar/fast" as just another feature. So when
we require the feature "foo/bar/fast", add_feature for foo will generate a
dependency on "foo" requiring that feature "bar/fast" is enabled. Then,
when resolving foo, add_feature will find that "bar/fast" is a required
feature, so it'll happily add "fast" as the required feature for the
dependency "foo".

The fix for this is to make sure that the `add_feature` function does
not treat `a/b` specifications as just another feature. Instead, it now
handles that case without recursion directly when it encounters it.

We can see how this resolves the above problem: when resolving foo,
add_feature for the required feature "bar/fast" will be called.
Because add_feature no longer treats such specifciations differently at
the top level, it will try to enable a feature with the exact name
"bar/fast", and Context::resolve_features will later find that no such
feature exists for package foo.

To give a friendlier error message, we also check in
Context::resolve_features that we never ever require a feature with a
slash in a name from a dependency.

Add owner subcommand to cargo's man page

Disallow specifying features of transitive deps

Before this commit, it was possible to activate a feature in a transtive
dependency, using a Cargo.toml like the following one:

    ...
    [features]
    # this will enable feature fast in package bar, which is a
    # dependency of foo
    default = [ foo/bar/fast ]

This is a bug, and was never intended, and it is checked in other places
already. The behavior was possible because `build_features::add_feature`
treats the specification "foo/bar/fast" as just another feature. So when
we require the feature "foo/bar/fast", add_feature for foo will generate a
dependency on "foo" requiring that feature "bar/fast" is enabled. Then,
when resolving foo, add_feature will find that "bar/fast" is a required
feature, so it'll happily add "fast" as the required feature for the
dependency "foo".

The fix for this is to make sure that the `add_feature` function does
not treat `a/b` specifications as just another feature. Instead, it now
handles that case without recursion directly when it encounters it.

We can see how this resolves the above problem: when resolving foo,
add_feature for the required feature "bar/fast" will be called.
Because add_feature no longer treats such specifciations differently at
the top level, it will try to enable a feature with the exact name
"bar/fast", and Context::resolve_features will later find that no such
feature exists for package foo.

To give a friendlier error message, we also check in
Context::resolve_features that we never ever require a feature with a
slash in a name from a dependency.